1. Field of the Invention
The present relates to techniques for improving computer system performance. More specifically, the present invention relates to a method and an apparatus that facilitates counting instructions for performance analysis purposes during speculative execution.
2. Related Art
Advances in semiconductor fabrication technology have given rise to dramatic increases in microprocessor clock speeds. This increase in microprocessor clock speeds has not been matched by a corresponding increase in memory access speeds. Hence, the disparity between microprocessor clock speeds and memory access speeds continues to grow, and is beginning to create significant performance problems. Execution profiles for fast microprocessor systems show that a large fraction of execution time is spent not within the microprocessor core, but within memory structures outside of the microprocessor core. This means that the microprocessor systems spend a large fraction of time waiting for memory references to complete instead of performing computational operations.
Efficient caching schemes can help reduce the number of memory accesses that are performed. However, when a memory reference, such as a load generates a cache miss, the subsequent access to level-two (L2) cache or memory can require dozens or hundreds of clock cycles to complete, during which time the processor is typically stalled (and therefore idle), performing no useful work.
A number of forms of “speculative execution” have been proposed or are presently used to prevent the processor from stalling when a cache miss occurs. Some processors support “out-of-order execution,” in which instructions are issued “out-of-order” when operands become available. Unfortunately, existing out-of-order designs have a hardware complexity that grows quadratically with the size of the issue queue. Practically speaking, this constraint limits the number of entries in the issue queue to one or two hundred, which is not sufficient to hide memory latencies as processors continue to get faster. Moreover, constraints on the number of physical registers which are available for register renaming purposes during out-of-order execution also limits the effective size of the issue queue.
Some processor designers have proposed generating a checkpoint and entering a “scout mode” during processor stall conditions. In scout mode, instructions are speculatively executed to prefetch future loads, but results are not committed to the architectural state of the processor. For example, see U.S. patent application No. 10/741,944, filed 19 Dec. 2003, entitled, “Generating Prefetches by Speculatively Executing Code through Hardware Scout Threading,” by inventors Shailender Chaudhry and Marc Tremblay. By avoiding the need to re-order instructions that were issued out-of-order, the scout mode technique avoids the need for complex instruction control structures. However, the scout mode technique suffers from the disadvantage of having to re-compute results of computational operations that were performed during scout mode.
To avoid performing some of these re-computations, processor designers have proposed entering an “execute-ahead” mode when the processor encounters a data-dependent stall condition. In execute-ahead mode, the processor defers instructions that cannot be executed because of unresolved data dependencies and executes other non-deferred instructions in program order.
When a data dependency is ultimately resolved, the processor transitions to a “deferred mode” to execute the deferred instructions. In deferred mode, the processor executes deferred instructions that are able to be executed while re-deferring deferred instructions that still cannot be executed because of unresolved data dependencies. For example, see U.S. Pat. No. 7,114,060, filed 14 Oct. 2003, entitled, “Selectively Deferring the Execution of Instructions with Unresolved Data Dependencies as They Are Issued in Program Order,” by inventors Shailender Chaudhry and Marc Tremblay.
To achieve good performance, it is desirable to be able to measure the performance of processor designs that support the above-described speculative-execution techniques while executing real program code. These performance measurements can then be used to optimize system performance. For example, runtime compilers can use performance measurements to dynamically optimize code. Similarly, operating systems can use performance measurements to determine how processes interact, which allows the operating systems to efficiently schedule the processes to optimize interactions between processes.
Unfortunately, there presently exists no accurate way to measure processor performance during speculative execution. For example, instructions which are executed during execute-ahead mode do not actually perform useful work unless execute-ahead mode completes successfully. Hence, it is not clear whether instructions that are completed during execute-ahead mode should be added to the count of executed instructions.
When such performance measurements are inaccurate, users of the performance measurements, such as processor designers, programmers, operating systems, and compilers, use these inaccurate performance measurements to make design sub-optimal decisions which can lead to sub-optimal system performance.
Hence, what is needed is a method and an apparatus for evaluating the performance of a processor that supports speculative execution without the above-described problems.